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Response to Arguments 

1 . Applicant's arguments filed on July 22, 2009 have been fully considered but they 
are not deemed to be persuasive. 

2. On pages 1 6-1 7, applicant's representative argues that: 

Applicant respectfully submits that the Office Action has attempted to identify 
corresponding elements, for those of claim 1 , in Lawande by selecting features of any 
elements without consideration for the factual association described in the description. 
This is improper, as both the claims and the references must be considered as a whole, 
and the claims must be read in light of the specification. 

Certain embodiments of the present invention involve the provision of a number 
of fields within the header of the transported packet, such as an IP, or OBEX type 
packet, where (on the other hand) Lawande discusses the provision of fields in the 
header of the enveloping layer IEEE 1394. 

The Office Action responded by noting that "IP" and "OBEX type" are not found in 
the claims. However, Applicant respectfully submits that the context of the application 
provides light on the claims, as the Office Action admitted: "the claims are interpreted in 
light of the specification" (Office Action, page 9). Thus, the discussion in the 
specification must not be ignored in properly construing the claims, and the discussion 
in the specification places boundaries on what the broadest reasonable interpretation of 
the claims is. 

Examiner respectfully disagrees. 
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If Applicant argues that the claimed fields belong to headers of IP or OBEX type 
packets, Examiner does not see such a limitation in the claims. In response to 
applicant's argument that the references fail to show certain features of applicant's 
invention, it is noted that the features upon which applicant relies (i.e., IP or OBX type 
packets) are not recited in the rejected claim. Although the claims are interpreted in 
light of the specification, limitations from the specification are not read into the 
claims. See In re Van Geuns, 988 F.2d 1181, 26 USPQ2d 1057 (Fed. Cir. 1993). 

Examiner further emphasizes that limitations from the specification are not read 
into the claims, as applicant's representative only repeated partially what Examiner 
stated, "claims are interpreted in light of the specification", and left out the critical aspect 
of Examiner's response. 

3. Applicant's representative further argues that: 

From Figure 5 of Lawande it is evident that the IP packet is provided on a 
different layer than the Common Packet Header (CPR), which is a part of the IEEE link 
layer, as that term would be understood to one of ordinary skill in the art. Furthermore, 
in column 17, in Lawande, it is stated that the protocol IEEE 1394 "has a field in the 
header which has memory information of the target of the packet of the data." However, 
to integrate the two protocols, the field is modified, putting in the "protocoltype" field in 
the packet header. 

Hence, it is clearly shown that the "protocoltype" field according to Lawande is 
located in the header of the IEEE 1394 protocol, whereas the "data payload type" field 
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according to certain embodiments of the present invention is located in the header of 
the transported packet, or (more specifically) the data segment. This is further 
supported in the description portion of the present application on page 15, lines 18- 21 : 
"in this context when referring to a header section, the header section of the data 
segment is meant unless specifically stated otherwise." Accordingly, Lawande does not 
disclose a protocol type identifier in the header of the encapsulated data segment. 
Examiner respectfully disagrees. 

In response to applicant's argument that the references fail to show certain 
features of applicant's invention, it is noted that the features upon which applicant relies 
(i.e., the "data payload type" field is located in the data segment) are not recited in the 
rejected claim(s). Although the claims are interpreted in light of the specification, 
limitations from the specification are not read into the claims. See In re Van Geuns, 988 
F.2d 1181,26 USPQ2d 1057 (Fed. Cir. 1993). 

As a recap of the rejection of claim 1, Lawande discloses ... a data link layer 
comprising a first header field for data payload type and a second header field for a data 
link layer version (Fig. 5, 1394 Link Layer 40; Fig. 7C, protocoljype and pn_version 
corresponding to data payload type and data link layer version, respectively; col. 1, lines 
46+; col. 5, lines 41, 42; IP packet encapsulated in IEEE 1394 packet, i.e., data link 
layer). 

In particular the claim recites a data link layer comprising the data payload type, 
constituting the IEEE 1394 link layer comprising the protocol type in Lawande ("One 
example of a physical and link layer medium is the IEEE 1 394 high speed serial bus" 
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(col. 2, lines 1, 2), i.e., IEEE 1394 corresponds at least to the data link layer; the 
"protocoltype" field is put in the IEEE 1394 packet header (col. 17, lines 15-21), and the 
"protocol_type field may be modified based on the configuration of the system to 
indicate the type of packet encapsulated in the field" (col. 17, lines 38-40), i.e., protocol 
type filed, which indicates type of encapsulated packet, corresponds to the data payload 
type; thus the protocol type field in IEEE 1394 header reading on the claimed limitation 
of data link layer comprising a first header field for data payload type) 

4. Applicant's representative further argues that: 

In response to the above, the Office Action stated disagreement and reiterated a 
portion of the rejection verbatim, neither of which is a response that advances 
prosecution, since Applicant has already explained the deficiencies of the rejection as 
stated. 

In addition, the Office Action stated: "the claim recites a data link layer 
comprising the data payload type, constituting the IEEE 1394 link layer comprising the 
protocol type in Lawande." However, it is unclear how this is supposed to address the 
distinctions identified above, since it seems simply to be a conclusory assertion that the 
mapping in the claims is proper. 

Examiner respectfully disagrees. 

Please refer to response above. It is noted that the rejection, when reiterated in 
the response, clearly explains the mapping between the prior art and the claims. 
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5. Applicant's representative further argues that: 

More specifically, certain embodiments of the present invention relate to the 
provision of a "data payload type" field in the header of the data segment encapsulated 
in between the two segments of the physical layer referred to in claim 1 and shown (in 
one embodiment) as 12a and 12b in Fig. 1a. This, however, is not reflected in fig. 7c in 
Lawande, because Lawande does not disclose what is recited in claim 1 . 

Examiner respectfully disagrees. 

In response to applicant's argument that the references fail to show certain 
features of applicant's invention, it is noted that the features upon which applicant relies 
(i.e., data segment encapsulated in between the two segments of the physical layer 
shown in the drawings of the disclosure) are not recited in the rejected claim(s). 
Although the claims are interpreted in light of the specification, limitations from the 
specification are not read into the claims. See In re Van Geuns, 988 F.2d 1 181 , 26 
USPQ2d 1057 (Fed. Cir. 1993). 

6. Applicant's representative further argues that: 

Lawande, furthermore, would not lead one of ordinary skill in the art toward the 
claimed invention. Lawande has been considered (by the USPTO) as the closest prior 
art, since it allegedly has some elements in common. The objective problem to be 
solved by a person of ordinary skill in the art in light of Lawande could be characterized 
as follows: How to integrate IEEE 1394 protocols with IP protocols. A person of ordinary 
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skill in the art facing this problem could perhaps, in light of Lawande, know how to 
integrate a IEEE 1394 protocol with IP protocols. 

It would not, however, be obvious for a person of ordinary skill in the art to 
provide a header of a data segment with a field specifying the content of said specific 
data segment. More specifically, certain embodiments of the present invention relate to 
the provision of backward and forward compatibility of a data link layer protocol in a 
system of connecting modules through a port connection. Further, another object of 
certain embodiments of the present invention relate to the way of managing packets of 
a number of different protocols simultaneously. These objects (nor any similar) cannot 
be found in the cited art. Thus, the cited art would not lead one of ordinary skill in the art 
toward the claimed invention. 

The Office Action responded by noting that "backward and forward compatibility" 
and "way of managing packets of a number of different protocols simultaneously" are 
not found in the claims. However, Applicant respectfully submits that the advantages of 
certain embodiments of the present invention do not have to be recited to provide 
evidence of non-obviousness. Thus, the advantages must not be ignored in properly 
assessing the non-obviousness of the claims, and the discussion of the advantages 
provides evidence that would rebut a prima facie case of obviousness, if such had been 
presented (not admitted). 

Examiner respectfully disagrees. 

In response to applicant's argument that the references fail to show certain 
features of applicant's invention, it is noted that the features upon which applicant relies 
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(i.e., compatibility and different protocols simultaneously) are not recited in the rejected 
claim. Although the claims are interpreted in light of the specification, limitations from 
the specification are not read into the claims. See In re Van Geuns, 988 F.2d 1 181 , 26 
USPQ2d 1057 (Fed. Cir. 1993). 

7. Applicant's representative further argues that: 

The Office Action also repeated a portion of the rejection and pointed out that the 
alleged mapping between Lawande and the claims is between the claimed physical 
layer and the physical layer of Lawande. The Office Action also stated, "An alternate 
interpretation is that the physical layer is formed by data from the upper layers, and 
Lawande discloses the format of IP packet together with the IEEE 1394 layer, thus 
forming first and second segments at the physical layer." It is unclear why the Office 
Action has taken the position that something other than the physical layer of Lawande 
should alleged correspond to the physical layer of the present claims. To the extent that 
this alternative ground is relied upon, it is respectfully submitted that it requires reading 
the claims in an unreasonably broad way. 

Examiner respectfully disagrees. 

As a recap of the rejection of claim 1, Lawande discloses ... a physical layer 
comprising a first and a second segment to encapsulate other layers in said data 
package (Fig. 5, 1394 Physical Layer 40, protocols TCP, UDP, IP, 1394 Link Layer in 
other layers; col. 1, lines 47+; col. 11, line 56 to col. 12, line 28; OSI model having lower 
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layer encapsulating upper layers; IEEE 1394 physical layer including parameters, i.e., 
first and second segments, and encapsulated upper layers). 

The examiner notes the broadest reasonable interpretation in light of Applicant's 
specification. The claimed physical layer corresponds to the IEEE 1394 physical layer 
of Lawande, and as it is well known to one of ordinary skill in the art, IEEE 1394 
specification provides for parameters, i.e., first and segments, necessary for 
transmission of encapsulated data from upper layers. 

8. Applicant's representative further argues that: 

Additionally, Lawande does not disclose "an offset value for determination of data 
payload start in said data package," as recited in (for example) claim 1 . According to the 
description of the present application, on page 5, line 28, to page 6, line 3, the offset 
value can provide means for compensating for future changes to the network/transport 
protocols, since the receiving module (through the offset value) may jump directly to the 
payload start when the receiving module does not require the potential data from the 
header. 

Furthermore, according to the description of the present application on page 18, 
lines 20-28, the offset field can be incorporated in the header section to make the 
header backward compatible. When future fields are added to the header, any software 
can forward payload data even though the software is aware of the additional fields, 
since the software may forward the data package based on the Offset and the Version 
field. Hence, this field can permit compensation for future extensions of the header 
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section, as there might be a need in the future for additional fields in the header. These 
extensions can be added while still being backward compatible, the Offset field will tell 
the receiving entity where the actual data package starts. 

In contrast to the above, and in contrast to the feature "an offset value for 
determination of data payload start in said data package," the common packet header in 
Fig. 7C of Lawande contains a destination offset field in order to comply with the IEEE 
1394's requirement of including memory architecture information. However, the 
reference to ip_fragment_offset in Lawande is a part of the IP protocol, which has to do 
with fragmenting a large non-IP packet into several, smaller IP packets. More 
specifically, to fragment a datagram, the header size is used to calculate how many 
fragments are required. The header of the original datagram is then copied into the 
headers of each of the fragments. The fragment offset reflects the position of the 
fragment within the original datagram. Each fragment becomes its own datagram and is 
routed independently of any other datagrams. This makes it possible for the fragments 
of the original datagram to arrive at the final destination out of order. At the final 
destination, the fragment offset field tells the receiver how to order the fragments. 
Hence, the concept of the Offset field according to the discussion in the present 
application's specification (and recited in claim 1: "an offset value for determination of 
data payload start in said data package") is not disclosed in Lawande. 

Indeed, in Lawande there is nothing that would lead a person skilled in the art 
closer in respect of using an offset field in the way it is used according to the present 
claims. Furthermore, the solution according to Lawande may have a number of 
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drawbacks. Firstly, the protocol_type field is multiplexed with the memory information 
field, making it complex when decoding the field. Secondly, the solution according to 
Lawande renders it difficult or impossible to mix different protocol types in the same 
connection. Lawande is specifically designed for transfer of IP messages, whereas 
certain embodiments of the present invention allow a combination of multiple protocols 
sent simultaneously on the same connection without resetting or changing its state. For 
instance, OBEX and IP packages can be sent alternating in respect to each other 
without resetting the connection. 

The Office Action, at pages 15-16 responded similarly to the previous responses, 
and the Office Action's responses have similar flaws. In particular, the Office Action 
insisted that one of ordinary skill in the art would have found it obvious "to use an offset 
field similar to the fragment offset field, e.g., the payload offset field, to determine the 
start of the payload. Thus Lawande discloses "an offset value for determination of data 
payload start in said data package," as claimed" (Office Action, page 16). Applicant 
respectfully disagrees. 

First, Lawande does not disclose "an offset field similar to the fragment offset 
field." Lawande specifically mentions "ip_fragment_offset" and does not suggest or in 
hint in the least that any variation at all to this field is either possible or desirable. 
Accordingly, Lawande does not fairly disclose or suggest using "an offset field similar to 
the fragment offset field." 

Second, Lawande's "ip_fragment_offset" or anything like it would not correspond 
to the "an offset value for determination of data payload start in said data package," as 
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recited in (for example) claim 1 . The ip_fragment_offset field identifies an offset, but it is 
not an offset that expresses a relationship within the packet itself. The offset expressed 
by ip_fragment_offset is an offset of the content of the fragment with respect to an 
original packet upon which the fragment is based. This could be called an "inter- 
package" offset. 

In contrast, the offset recited in the claim is an offset that is expressed with 
respect to the data package that contains the offset field. Thus, this could be called an 
"intra-package" offset. Thus, the two different kinds of offsets (inter-package offset and 
intra-package offset) have completely different functions and roles in the packet. 
Accordingly, it would not be obvious to one of ordinary skill in the art to change one kind 
of offset into the other, because doing so would fundamentally alter the operation of the 
field. 

Specifically, if one made the ip_fragment_offset field into an offset that 
determined "data payload start in said package" (as contrasted with the payload start in 
an original packet from which the package is derived as in the ip_fragment_offset 
instance), then the ip_fragment_offset field would not work properly, since it would not 
permit the reassembly of a fragmented original packet, which is what its purpose is in 
Lawande. 

Such a change, therefore, would necessarily render Lawande inoperable for its 
intended purpose. MPEP 21 43.01 (V) states "THE PROPOSED MODIFICATION 
CANNOT RENDER THE PRIOR ART UNSATISFACTORY FOR ITS INTENDED 
PURPOSE," (Capital letters in original.) and explains that "If proposed modification 
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would render the prior art invention being modified unsatisfactory for its intended 
purpose, then there is no suggestion or motivation to make the proposed modification." 
Moreover, MPEP 2145(VI) states that "the claimed combination cannot change the 
principle of operation of the primary reference or render the reference inoperable for its 
intended purpose." Thus, in this case, since the proposed modification to Lawande's 
ip_fragment_offset would render Lawande inoperable for its intended purpose, such a 
modification is per se non-obvious. 

The Office Action further argued that "using a field in a message to determine the 
start of payload is well known in the art" and cited U.S. Patent No. 5,937,169 of Connery 
et al. ("Connery") as allegedly supporting this contention. However, as is plain from 
Figure 4 of Connery, the "data offset field" of Connery is in the TCP header, while the 
"fragment offset" (corresponding to Lawande's "ip_fragment_offset") is found in the IP 
header of Connery. Thus, Connery does not provide motivation to modify Lawande's 
"ip_fragment_offset" into a "data offset" as shown in Figure 4 of Connery, nor into the 
claim features. 

Furthermore the proposed motivation to modify Lawande is plainly erroneous. 
The Office Action stated that the reason for the modification would be "in order to 
quickly identify the start of the payload and thus effectively perform packet processing." 
This motivation is fundamentally flawed. Lawande is presumptively already able to 
perform packet processing. If packet processing could not be performed on Lawande's 
packets without further modification, then Lawande would not be enabled, but U.S. law 
presumes that granted patents are enabled. 
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Furthermore, adding an additional field to Lawande would not be expected to 
enhance the speed of finding the start of the payload in Lawande. Lawande's structure 
as illustrated in Figure 7C requires that the payload starting point in Lawande is always 
the same and therefore already known a priori to the processing system. Adding a data 
field that conveyed already known information would be against common sense. Thus, it 
would not have been obvious to one of ordinary skill in the art to include such a field in 
Lawande's structure. Therefore, it is respectfully maintained the rejection is improper 
and should be withdrawn. 

Examiner respectfully disagrees. 

As a recap of the rejection of claim 1 , it is noted that using a field in a message to 
determine the start of payload is well known in the art. For example, it is well known in 
the art that the ASCII character set, the first and foremost specification for encoding of 
information for communication, defines control codes Start of Header (SOH) and Start 
of Text (STX), the latter is an indication in the data stream to determine the start of the 
data, i.e., payload. Furthermore Lawande discloses ip_fragment_offset (Fig. 7C). It is 
well known to one of ordinary skill in the art at the time of the invention that an IP 
payload comprises IP fragments, and fragment offset is used to indicate the start of a 
particular fragment, and since each fragment is transmitted in an IP datagram, the 
fragment offset in effect provides the start of the payload in that datagram. Thus it 
would have been obvious to one of ordinary skill in the art at the time of the invention to 
use an offset field similar to the fragment offset field, e.g., the payload offset field, to 
determine the start of the payload. 



Application/Control Number: 1 0/571 ,290 Page 1 5 

Art Unit: 2416 

Furthermore, Connery et al (US Patent 5,937,169, i.e. WO 99/22306, prior art 
reference provided in Information Disclosure Statement by Applicant form) discloses a 
Data Offset field which indicates where the data payload begins (Fig. 4, element 112; 
col. 12, lines 18+). Thus it would have been obvious to one of ordinary skill in the art at 
the time of the invention to include the data offset field as taught by Connery in the 
header of packet in the system of Lawande in order to quickly identify the start of the 
payload and thus effectively perform packet processing. 

As per MPEP 2141 , the Court in KSR identified a number of rationales to support 
a conclusion of obviousness which are consistent with the proper "functional approach" 

to the determination of obviousness as laid down in Graham. KSR, 550 U.S. at , 82 

USPQ2d at 1395-97. Note that the list of rationales provided below is not intended to be 
an all-inclusive list. Other rationales to support a conclusion of obviousness may be 
relied upon by Office personnel. 

Exemplary rationales that may support a conclusion of obviousness include: 

(A) Combining prior art elements according to known methods to yield 
predictable results; 

(B) Simple substitution of one known element for another to obtain predictable 
results; 

(C) Use of known technique to improve similar devices (methods, or products) in 
the same way; 

(D) Applying a known technique to a known device (method, or product) ready for 
improvement to yield predictable results; 
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(E) "Obvious to try" - choosing from a finite number of identified, predictable 
solutions, with a reasonable expectation of success; 

(F) Known work in one field of endeavor may prompt variations of it for use in 
either the same field or a different one based on design incentives or other market 
forces if the variations are predictable to one of ordinary skill in the art; 

(G) Some teaching, suggestion, or motivation in the prior art that would have led 
one of ordinary skill to modify the prior art reference or to combine prior art reference 
teachings to arrive at the claimed invention. See MPEP § 2143 for a discussion of the 
rationales listed above along with examples illustrating how the cited rationales may be 
used to support a finding of obviousness. See also MPEP § 2144 - § 2144.09 for 
additional guidance regarding support for obviousness determinations. 

As recited in the rejection of claim 1, the claim limitation "a fifth header field for an 
offset value for determination of data payload start in said data package" reads on the 
prior art of record, as recited in the rejection of claim 1 , in Lawande, Connery and well 
known technique in ASCII character specification. 

In response to applicant's argument that Connery's offset field is in the TCP 
header. It is noted that the claimed limitation of the fifth header field is located in the 
network/transport layer which corresponds to the TCP layer. It is well known in the art 
that the use of data offset field is not limited to only one specific layer of the OSI layered 
architecture. 

In response to applicant's argument that there is no suggestion to combine the 
references, the examiner recognizes that obviousness can only be established by 
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combining or modifying the teachings of the prior art to produce the claimed invention 
where there is some teaching, suggestion, or motivation to do so found either in the 
references themselves or in the knowledge generally available to one of ordinary skill in 
the art. See In re Fine, 837 F.2d 1071 , 5 USPQ2d 1596 (Fed. Cir. 1988)and In re 
Jones, 958 F.2d 347, 21 USPQ2d 1941 (Fed. Cir. 1992). In this case, the use of data 
offset field is used to identify the start of the payload, as is often used in parsing of 
communications data. 
/Huy D Vu/ 

Supervisory Patent Examiner, Art Unit 2416 



